The so-called anti-virus (“AV”) “in-the-cloud” service has been advocated as a next generation model for virus detection. It is a software distribution model in which security services are hosted by vendors and made available to customers over the Internet.
This approach employs a set of “cloud” (i.e., Internet) servers which analyze and correlate new attacks and generate vaccinations online. With this infrastructure, in-the-cloud service can sharply reduce the computing burden on client computers, and make security products more effective in stopping new malware. Furthermore, customers do not need to install a full copy of the virus signature file, and need only keep a small set of “cloud signatures.” The benefits include easy deployment, low cost of operation, and fast signature updating.
In operation, the in-the-cloud service can work as follows. For a suspicious file identified on a user computer, rather than the typical client-based virus signature scanning, the desktop application instead calculates the hash value of the file and sends it to the remote cloud server, which will then compare that value to the continuously updated signature database available at the cloud server. If the value exists in the database, the client will be asked what specific action he or she wants the desktop application to take on the infected file. For example, a user can choose to quarantine, block, or even clean the detected file.
AV cloud services become more attractive attack targets because putting a cloud server cluster offline is more disastrous than compromising a single machine. Therefore, preventing cloud servers from being attacked has become a critical issue. The communication link between a desktop and a cloud server is over the Internet and is vulnerable if the link is offline or unavailable. To defend against technical network attacks, cloud servers can hide their identities via cryptography and anonymity but still are vulnerable to traffic analysis. By using statistical analysis coupled with traffic analysis, an attacker can determine the next node to which packets will be sent. With the gained link information, the attacker can launch a denial-of-service attack on the cloud servers.
FIG. 1 shows a typical anti-virus in-the-cloud infrastructure 10. Shown is a user computer 20, an anonymous network 40 and an in-the-cloud service 50. Anonymous networks are used to provide private and secure communications for a variety of applications. One important feature an anonymous network provides for an in-the-cloud service is that a server can communicate with a user without releasing its real identity. Using an anonymous network to send out a packet containing a hash value of a suspicious file, the desktop software chooses a set of authorized anonymous nodes and incrementally creates an encrypted circuit to a cloud server. Since each anonymous circuit is extended one node at a time, a node in the link only knows the immediately previous and following nodes. Thus, an eavesdropper on a compromised node cannot determine the complete link information between the desktop application and the cloud server.
Generally speaking, anonymous networks fall into two categories: high-latency and low-latency networks. A big drawback, however, of a high-latency network is that it will introduce long delivery delays.
On the contrary, low-latency anonymous networks are suitable for interactive applications such as web browsing and online chatting. In an in-the-cloud service, the communication between a desktop and a server over the Internet requires as little as hundreds of milliseconds, which requires especially low latency. These low-latency networks can be susceptible to traffic analysis.
Even with an anonymous network 40 as shown in FIG. 1, an attacker can use a traffic analysis. In this type of attack the attacker inserts probing traffic into the network (usually by compromising a user computer) that has a unique pattern and timing. Thus, the user computer is sending normal packets as well as malicious probing packets. This probing traffic can be distinguished by the attacker as the traffic travels through the routing nodes of the network. The attacker can then figure out which routing nodes are used and which are next, thus being able to determine the path between the desktop agent and the cloud server 60. An attack may then be launched on the server (such as “denial of service”) causing instability in the service, etc. Attacks may also be launched upon the intermediate nodes as well.
Defending against Traffic Analysis Attacks with Link Padding for Bursty Traffics, Proceedings of the 2004 IEEE Workshop on Information Assurance, June 2004, describes a technique to defend against traffic analysis using a link padding algorithm. But, this paper is directed toward defending against an adversary having a global view who can observe the entire network, rather than an adversary who can only observe part of the network. An adversary attacking a low-latency anonymous network may only need to view and control a user computer and the first anonymous node. Further, this paper aims to protect the links between intermediate routing nodes, and it requires both a traffic buffer and a constant-length buffer. Finally, its timer is only dependent upon the timeout generator.
It is desirable to defend against traffic analysis used against in-the-cloud services, especially with a low-latency network.